Support restored Office functionality on macOS by removing corrupted application bundles from /Applications (deleting the app bundle and emptying the Trash) and reinstalling the supported Microsoft 365 package from Jamf Self Service; removing Dock icons alone had not helped. For many managed devices, running the Self Service “Office Repair” action (IU Self Service / Office Reparieren) restored apps without a full reinstall. Temporary local elevation via the Self Service Portal’s Admin‑Minion was used where users lacked admin/App Store permissions. Reinstalls or repairs typically resolved mislabeling, restored Word’s PDF export options (including “Best/Optimal for printing”), cleared Outlook “Upgrade Required” states, and removed recurring startup error dialogs; freshly reinstalled apps sometimes only launched from Launchpad and a restart was performed when noted.

Repeated runtime error 32815 and other startup failures were repeatedly traced to third‑party Office add‑ins, notably Adobe Acrobat helper/add‑ins and Efficient Elements. Removing Acrobat add‑ins from Office startup locations (including ~/Library/Group Containers/UBF8T346G9.Office/User Content/Startup) or running the SelfService+ “Adobe Acrobat Add‑in Removal for Microsoft 365” script cleared those errors in multiple cases. When the Self Service removal action stalled or reloaded without deleting the add‑in, support used Admin‑Minion elevation to run the SelfService+ removal script or performed manual deletion from the Group Containers startup locations. Efficient Elements add‑in failures that did not appear in the Add‑ins list were resolved by updating the device’s configuration/profile when uninstall/reinstall and disabling macros had not.

Some systems required upgrading macOS (example: Sequoia 15.3.2 → 15.5) before a Self Service reinstall or repair would succeed; on devices where a reinstall/repair initially failed, applying a subsequent Outlook/Office update (after the reinstall) restored launch ability. New Macs that arrived without the corporate Self Service Portal were escalated for reimaging or MDM remediation; Teams and Outlook were sometimes installed individually but the full Microsoft 365 package was unavailable without the Portal. Devices that presented Company Portal sign‑in errors stating they were registered with another device management provider were treated as MDM enrollment conflicts and handled via escalation for MDM remediation or reimage (attempts to follow intranet restore guidance were observed to hang some Macs, requiring a restart). For private (non‑corporate) hardware support was not provided; users were directed to reinstall Microsoft 365 desktop apps themselves using corporate desktop installers or Microsoft. As temporary workarounds, Office web apps were used and users were advised that freshly reinstalled apps could initially appear only in Launchpad or require a restart.

Multiple related failure modes were observed during Microsoft 365 provisioning and post-provision updates on Windows devices (notably new Windows 11 laptops, some Dell systems, and Windows VMs). Resolutions and findings that completed provisioning or cleared update failures included:

Impacted devices were recovered through three outcomes observed across incidents. 1) In many cases running Dell SupportAssist OS Recovery and allowing the OS recovery process to finish completed automatic provisioning; after the device completed Intune/Company Portal enrollment the Office 365 desktop apps, OneDrive provisioning, and Company Portal returned, missing applications became searchable, and the Microsoft Store regained availability. 2) On devices where recovery was not required or where SupportAssist had already completed, technicians finalized Office 365 account sign-in and Windows Hello/PIN configuration in-person and then reinstalled Office; this restored email access and desktop Office functionality (users who had been editing via Okta web regained local 'Save As' once the local Office installation and provisioning completed). Technicians noted manual installer attempts prompted for administrative credentials until MDM/Company Portal provisioning had fully completed. 3) On devices where the Dell OneTime Boot Menu (F12) could not be accessed or where the device was not registered in Intune/Company Portal (preventing remote reinstall), technicians performed onsite registration or alternative recovery/repair actions to enroll the device before re-provisioning; where recovery or re-provisioning did not restore a usable system a replacement device was issued.

Users accessed their mailbox via the Okta web Outlook client while a Store‑based update requirement prevented use of the desktop Outlook app; that temporary web access was documented. For the blocked Store and PowerPoint installation incident, support confirmed the Microsoft/M365 Store block on the Windows 11 corporate device was intentional per policy, and the user acquired Microsoft applications through the Company Portal instead of the Store. The original Outlook ticket recorded only the temporary web workaround and did not document a permanent change to Store installation permissions.

Across incidents a consistent set of client, device, browser and tenant-side actions repeatedly reconciled the observed Teams UI, messaging, media and notification faults. Transient client-state faults were repeatedly resolved by fully terminating Teams, clearing the Teams cache (Windows classic: %appdata%\Microsoft\Teams; Windows app‑packaged: C:\Users\%username%\AppData\Local\Packages\MSTeams_8wekyb3d8bbwe\LocalCache\Microsoft\MSTeams; macOS: ~/Library/Application Support/Microsoft/Teams/), signing out and back in, or using the Teams web app in a private/incognito browser session. When cache resets failed, Windows App Repair/Control Panel repair or a full uninstall with cleanup and clean reinstall restored startup; several cases required WebView2/runtime repair or reconciliation before reinstalls succeeded. Tenant- or app-level metadata visibility divergences (search/navigation targets, Outlook-link mismatches, missing teams/channels/files) were resolved by tenant/app-level synchronization or escalated to the Microsoft product group when client repairs did not restore metadata visibility. macOS incidents included clients blocked by permission or credential prompts, M1-specific launch failures, and provisioning/MDM discrepancies where redeploying or performing a clean install restored the client. Media and peripheral faults frequently tracked to device selection, drivers, docks/DisplayLink and vendor utilities: explicitly selecting a non-generic audio/video device, substituting headsets, and updating vendor utilities and firmware (examples observed: Dell Command Update, Dell SupportAssist, Dell Display and Peripheral Manager, Lenovo System Updater) stabilized one-way/silent/choppy audio and screen-sharing. Updating DisplayLink/dock drivers, audio drivers, BIOS/firmware and closing conflicting background apps resolved many microphone and camera failures; in one incident Lenovo System Update itself crashed while troubleshooting device-level faults. Meeting/call join delays commonly ranged ~30 seconds to 2 minutes and were sometimes accompanied by delayed camera initialization or transient inability to share the screen. Hardware failures and situations that prevented remote support (VPN/credential failures) were exhausted to hardware replacement in several incidents. A subset of peer-specific client crashes (client crash when calling a particular user) remained unresolved by client-side repairs and were escalated. Support also noted that meeting or recording audio loss was sometimes irrecoverable after the fact and that quick pre-meeting checks were recommended. Regarding notifications, testing in the Teams web app and verifying granular notification and channel notification settings reconciled some cases; however, one observed case showed that enabling then disabling an additional notification option caused persistent irrelevant notifications that did not revert after a restart and required further troubleshooting or escalation. No single tenant- or client-side remediation covered every notification anomaly in the corpus.

Incidents traced to a compact set of tenant/directory, client/session, integration, and Microsoft-service behaviors; observed resolutions and outcomes included the following.

Practical outcomes across incidents included staged update-policy rollouts, reassigning owners or recreating teams to clear stuck membership, restoring content from third‑party backups when native retention had expired, remediating enterprise‑app consent and registrations for bot/app failures, correcting dynamic-group rules or attribute mappings for persistent membership gaps, and escalating tab-creation, guest-app, or rendering errors to vendors or Microsoft when tenant configuration did not explain the symptom.

Incidents were traced to Microsoft 365 license removals, missing assignments, or temporary reduced licenses on affected accounts. Removing or lacking an Office/Microsoft 365 license had deprovisioned Exchange Online mailboxes and removed mailbox forwarding configurations, producing Exchange mailbox/non-existence errors and preventing messages from reaching Freshdesk and Salesforce queues. Restoring the appropriate Microsoft 365/Office license re-provisioned Exchange Online mailboxes and allowed forwarding rules to be recreated or restored; after license re-assignment inbound mail to reminder addresses resumed and external ticket queues began receiving messages again. In cases where users saw application access errors in Teams or Outlook (for example, "You don't have the required permissions to access this org"), assigning the required Office license restored application access and caused Office apps to reappear in the Office 365 dashboard. Some accounts that received a reduced or updated license after a return-to-work experienced a brief propagation delay; waiting a few minutes after the license change typically allowed sign-in/access to recover without further intervention.

Incidents traced to two primary causes, with an additional local-OS exception observed. First, mailbox/calendar timezone settings at the Exchange/Office 365 level were sometimes different from a user's local clock or microsoft.com profile; Teams (desktop and web), Outlook (desktop and web), Outlook on the web and downstream services consistently read the mailbox timezone. Correcting the mailbox/calendar timezone in Outlook on the web (office.com / outlook.office.com) restored expected meeting times and availability; in several cases the web UI required an explicit confirmation for the change to take effect. Where desktop UI changes did not propagate reliably, the mailbox timezone was corrected at the server/mailbox level (for example via Exchange admin tools or PowerShell). Clients that continued to display the old timezone were observed to re-sync after signing out of Teams, clearing the Teams client cache, and restarting. Second, persistent presence issues were traced to calendar items set to Show As = Out of Office: recurring events marked OOO caused Teams to remain in OOO status and changing those items cleared the OOO presence. Additionally, at least one incident was resolved by correcting a misconfigured local macOS timezone and the Teams time settings, indicating local OS timezone misconfiguration could produce the same symptoms. Microsoft Bookings was observed to present incorrect event times/timezones in automated invitation and reminder emails; in those cases an admin review of the Bookings calendar settings sometimes showed them already configured correctly, and one user-resolved Bookings display issue had no documented remediation steps.

Investigations identified several distinct causes and targeted remediations. Many incidents were traced to multiple signed‑in accounts, residual service accounts, or duplicate mailbox/license records; signing the user out of Office and OneDrive, removing secondary/service accounts, then re‑authenticating the primary Microsoft account re‑established OneDrive sessions and restored desktop app editing and saving to Teams/SharePoint. Transient access or permission failures (including Excel “access denied” dialogs) were repeatedly resolved by a full cold reboot because Windows fast‑startup or hibernation had preserved a bad process/state; when rebooting failed, clearing the Teams cache restored normal file access in several incidents. Persistent cases where desktop Office targeted a removed institutional account or stale license were linked to local cached credentials and SSO tokens that survived a plain reinstall; those were resolved after clearing local credential caches and residual account records, running Microsoft’s Office removal/cleanup tool, and reinstalling Office so desktop apps targeted the correct active account. Duplicate mailbox or account records were removed and users re‑signed in until their Microsoft 365 “Apps” portal item reappeared. OneNote sync/open failures were resolved by verifying the notebook in OneNote for the web (including the web recycle bin) and then re‑adding or reopening the notebook in the desktop app so the link refreshed; irrecoverable notebooks required creating a new notebook and importing contents. Web‑app feature losses and expired web sessions were restored by re‑authentication in the affected web app or by signing in at office.com or the institution’s SSO portal. Licensing‑related incidents were distinguished by confirming whether the Microsoft account existed but was licensed only for web apps: cloud‑only/A1 licences permitted editing only via office.com and not via locally installed Office (including on Mac). Some logins failed because the edu address was Google‑managed rather than a Microsoft account and thus rejected. On personal devices where users belonged to multiple Teams organizations, launching Teams from the office.com app launcher avoided a separate Teams sign‑in flow and prevented a sign‑in loop. On Windows 11 devices where Office could not find or activate the organizational account (including a user‑reported “it is not compatible with Windows” message when adding an account), re‑establishing the organization account through the Windows Settings access (Access work or school) reinstated the account so Office could activate against the correct tenant. Overall resolutions combined account/license confirmation on the Microsoft/Azure side with clearing local cached tokens and residual account records so desktop apps targeted the active, licensed account.

Support restored full desktop Office functionality by provisioning the Intune Company Portal’s published Microsoft 365 Apps (the packaged Office), which provisioned the full Microsoft 365 desktop suite (Word, Excel, PowerPoint) and related apps (Outlook, Teams, OneDrive, OneNote, Loop, Whiteboard) and avoided standalone‑installer admin prompts on supported devices. When a conflicting perpetual Office edition that lacked Outlook (for example Office Home and Student 2019) was present, support removed that installation as an administrator and then installed the Company Portal Microsoft 365 package; Outlook appeared after the packaged install. Support documented that manually downloaded or standalone installers often required local administrator rights and could prompt for an organizational email and an Administrator PIN, whereas the Intune‑managed package avoided those prompts. When the Company Portal or packaged Office was not immediately visible, support verified localized app names and the user’s sign‑in state (local Microsoft profile vs. organizational account), checked Company Portal/Okta entitlements and license assignment, and coordinated admin invitations, application‑approval requests or manager approvals as needed. Support noted that some requests for elevated installer rights were declined and users were directed to institutional access/portal flows (for example IU access) instead; manager‑approval gating sometimes prevented installs and tickets could remain open or be closed if approval was not provided. Support observed that launching an Office app from Windows Search occasionally triggered automatic provisioning, and that Company Portal / packaged Office could take several hours to appear unless the device remained powered and on the corporate network; connecting via Ethernet and preventing standby/lock improved availability. In environments that still used legacy Software Center (SCCM), missing apps were installed from that Software Center when available. Support confirmed that installing Office via the Company Portal did not require a VPN connection on Windows 11 and provided localized (German) installation instructions when requested. Missing third‑party apps (for example Google Chrome) were installed via the Company Portal when available. Support referenced the corporate “Office Installation - IT Onboarding” Confluence guide when assisting users.

Administrators located and removed obsolete Bookings pages through the Microsoft 365 admin portal (admin.microsoft.com) Bookings admin interface; when page name searches returned no results support located pages by pasting the page’s onmicrosoft.com booking email address into the Bookings search box, verified owners/admins, confirmed the pages were obsolete, and deleted them from the tenant. Deletion required tenant-level administrative privileges; users who were non‑admins, only team members, or only page‑level admins could not hide or delete pages or access the Bookings admin component. A separate issue where booking links hosted on outlook.office365.com were stuck in a continuous “building” state was resolved after the tenant’s business app (Geschäfts App / business app) was added to the environment; after the app was added the affected links loaded normally and related email delays cleared. In incidents that manifested as browser‑level or per‑user failures (login/authentication errors, broken links or inability to load outlook.office.com/book URLs), support performed client‑side troubleshooting including testing over alternate networks (mobile hotspot), clearing browser cache, and trying different Wi‑Fi; those steps were recorded as attempted while tenant‑side configuration changes were not present in the ticket.

Investigators confirmed the Power App only updated M365 group-level membership; Teams channel membership was maintained separately using Microsoft Graph calls from an app registration and automation. Migration and bulk-import failures were resolved by deduplicating source lists and correcting mismatched source attributes/locations before re-running imports. A PowerShell/Automation runbook bug was found in the GraphDelegPerm_RemoveExistingAddNewMembers routine: attempting batch-adds above a threshold (observed when member index >10 and tested ~30 members) caused unintended removals of existing members with no explicit error codes; those removals were visible in Azure AD audit logs and in SharePoint runbook logs. Affected memberships were restored using the adduser2group manual tool, and the runbook's batch-membership logic and Graph call usage were corrected to prevent further unintended removals. Automated enrollment and invitation to Teams Shared Channels used Azure AD dynamic groups (membership rules referencing extensionAttribute8/15 and similar attributes) combined with flows; transient membership-count discrepancies were attributed to dynamic-group sync timing, and invitation/enrollment attempts failed while a Microsoft service incident was active and resumed after the incident and dynamic-group sync completed. AddUser2Group exhibited a visibility/export outage that prevented requesters from seeing certain dynamic groups and exporting membership; support correlated this to an AddUser2Group/Microsoft service outage and membership reports returned once the service was restored. Cases where automations produced no visible posts (for example, Zoom Host Key postings) were traced to using the wrong service account UPN or to the flow living under a different owner/tenant; resolving these required identifying the correct service account and flow, ensuring the service account had channel membership (channel-level, not just M365-group membership) and that the flow's connectors/ownership were assigned to the appropriate service account. Situations requiring independent team management were resolved by cloning/recreating the Power Automate flow and assigning ownership and connectors to the target team's service account, adjusting the membership/target destination for the flow, and adding a scheduled welcome-message action so the new owning team could manage enrollments independently. Throughout, Azure AD audit logs, SharePoint runbook logs, and AddUser2Group visibility/export behavior were the primary diagnostics when no explicit error codes were present.

Microsoft Forms behaved differently depending on form-level settings and tenant sharing policies. Forms published as "Anyone with the link" produced truly anonymous submissions (the owner could not see individual respondent identities); forms set to "Only people in my organization" or forms with options that recorded identity (for example "Record name" or "One response per person") produced responses that were linked to sign-in accounts. Tenant-level sharing or security policies could prevent anonymous/public responses by forcing sign-in or by disabling the "Anyone can respond" option in the form settings (the option appeared greyed out and external users received access-denied errors). Investigations found non-policy causes for missing entries: respondents sometimes did not click the final Submit/Save so no submission was recorded, and submitted responses had occasionally been deleted after submission. Support staff were unable to open a form’s edit/design link until the owner granted them editor/collaborator permission; granting edit rights allowed inspection of form settings and stored responses and resolved troubleshooting barriers. Where enabling public responses was not permitted by tenant policy, a practical workaround used in support cases was creating a duplicate copy of the form specifically for the external group so those respondents could provide input.

Resolved by enabling Office Connected Experiences. All Office apps were closed, the desktop Word privacy settings (File → Options → General → Privacy Settings) were adjusted to allow 'Experiences that download online content', and Office was restarted. After Connected Experiences was enabled the Online Pictures image library was accessible again across desktop and web clients.

Access to Microsoft 365 Copilot had been provisioned either by adding users to the Copilot preview group or via an automated provisioning pipeline that only ran after users completed a required Copilot training/course; administrators verified A5 licensing where applicable. Users were required to personally accept Microsoft’s Copilot terms because Copilot was not covered by existing group contracts. Microsoft’s provisioning/automation commonly took up to 48 hours to enable Copilot functionality for newly provisioned users; availability was often confirmed by signing in through a private browser session.

Per‑application visibility issues were investigated and attributed in several cases to organizational policy exclusions (for example works‑council/vertretung groups) that had disabled Copilot for specific employee cohorts; these restrictions were communicated to affected users and support did not manually override them. Where Teams meeting Copilot scenarios or recording downloads were impacted, incidents were escalated to the Copilot project teams and the service teams owning recordings/streaming; investigation notes recorded that meeting-related Copilot defaults had been adjusted (Oct 2024) and that centrally enabled meeting scenarios sometimes required restarting the meeting for Copilot to activate. Repeated failures to download recordings (while streaming remained available) were raised to the relevant service teams for follow up.

Investigations into file access from OneDrive documented that the Copilot file pane and in‑app Copilot surfaced a short list of recently used OneDrive documents and did not provide a general browse/select option even when OneDrive sync was present; this behavior was flagged to product teams with relevance to semantic/indexing and Microsoft Graph search. Requestors were cautioned about including GDPR‑sensitive data in prompts and recordings and were informed about data‑protection implications for Copilot and meeting content.

Investigations identified several distinct root causes and corresponding outcomes. Mailbox/object-to-directory mapping mismatches (duplicate or guest mappings and mailbox‑to‑account mismatches) were resolved by consolidating or removing the duplicate/guest mappings and re‑associating mailboxes and service identities with the intended Azure AD accounts; after re‑association the correct profile and synced HR attributes appeared across services (propagation typically completed within hours but occasionally took longer). Out‑of‑date or incorrect authoritative directory attributes were corrected at the source (Azure AD or the HR system such as Workday); after normal synchronization corrected names, titles, and preferredLanguage populated Outlook, Teams, the GAL, Office desktop apps, and web portals (HR→Microsoft propagation for titles sometimes took a few days). It was observed that some renaming requests were blocked by the HR‑triggered (Workday) workflow when the account was an external/guest user without a Workday profile; those cases were not processed by the automated HR workflow and were resolved only after a Workday profile existed or the account/service identity was administratively re‑associated. Session/identity/profile‑source and client/OS language behavior explained transient anomalies where clients surfaced a Microsoft Account or an active session profile rather than organizational Azure AD attributes; these anomalies cleared after reauthentication, signing out/signing back in (and restarting clients), and clearing browser/session caches. Teams‑LinkedIn integration sometimes presented suggested external LinkedIn profiles when a user had not linked a personal LinkedIn account; those suggestions were produced by the integration/search and could not be changed by support. Microsoft Bookings links generated before a presenter’s email or display name change sometimes failed for external invitees with the error message “Error, we are unable to fulfil your request”; affected invitees were able to book after the presenter generated and sent a fresh Bookings link, and in some underlying cases a permanent fix required remapping the booking/service identity to the correct Azure AD account.

Support identified device-local session/credential mismatches and inconsistent on-device app state as the root causes rather than account-wide authentication failures. On managed iPads that used Okta/Okta Verify and YubiKey/WebAuthn, support cleared the stale Okta session bound to the device, reconciled MDM self‑service deployments by reinstalling the affected Microsoft apps, and re-enrolled the mobile MFA credentials (Okta Verify and the YubiKey/WebAuthn key). After clearing the local session, reconciling app installations, and re-registering mobile MFA factors, OneDrive and Office apps opened reliably and mailbox sign-in via Outlook succeeded. In a separate tablet case where browser-based sign-in failed and the YubiKey was not usable on-device, access was restored by using the Outlook app's account-unlock flow; after unlocking via Outlook the user regained access to other Office 365 apps and OneDrive without further changes.

Issues were resolved by treating permissions as per-Bookings-instance settings tied to the associated Exchange scheduling mailbox and by addressing mailbox, invite and licensing problems. In practice, a successor/service account was added as a Staff member inside the affected Bookings calendar and was assigned the Administrator role in that Bookings instance; the Service configuration (Teams/Staff settings) for the affected service(s) was edited to replace or include the service account so bookings and Teams notifications were delivered to the service account rather than the original creator. Where admin entries showed status "pendingAcceptance", access was restored after the user accepted the invitation email (Inbox or Junk); if no invitation existed, an existing active Bookings admin removed and re-added the pending account to force a new invitation which allowed the account to become active. Attempts to create Bookings pages that had failed were traced to accounts lacking an Exchange mailbox and a Bookings license; creating and signing in with a dedicated service account that had an Exchange mailbox and a Bookings license (signing in via an inPrivate browser session when cached credentials interfered) resolved those creation failures. A clarification observed across incidents was that Bookings does not have a classic "owner" object — administration and notification routing relied on per-instance admin/staff assignments and the scheduling mailbox rather than on a centralized global owner list. Service share links from a Service were used to provide direct access when needed.

The Bookings page was implemented as a single service to present only workshop timeslots while keeping the page organization-accessible. Date-limited availability was used: pre-defined workshop timeslots were created under the Bookings page’s Default scheduling policy using the 'Availability during these dates' option and general service availability was left unchanged so bookings were constrained to the explicitly created entries. It was clarified that Outlook/Microsoft 365 Calendar work hours do not synchronize with Bookings (including the Bookings app in Teams); changes made in Outlook did not propagate to Bookings. To resolve availability mismatches, staff availability entries were edited directly in the Bookings Admin for the affected Bookings page so the Bookings/Teams view matched the intended workshop timeslots.

When the Office.com/Outlook web UI presented only a "change" option, the profile picture was cleared using the Microsoft Teams profile-picture management UI and Teams/Outlook visibility subsequently reflected the removal. When users lacked a standalone image file because the picture was embedded in a Word or PDF, support produced an acceptable image (for example by exporting or capturing the embedded image to a jpg/png via Snipping Tool or equivalent) and the resulting file was uploaded to Teams/Outlook/Zoom. For accounts flagged as externally- or HR-provisioned where photo fields were not editable in the web UI, IT collected the user’s image and uploaded it directly to the account/profile so the new photo propagated to Outlook and Teams. Other profile attribute edits (job title, phone number) were changed by support or directory administration when required; those changes were observed to take up to 1–3 days to propagate across Teams/Outlook/Zoom.

Incidents were traced to client-side Teams cache or local-data mismatches. Technicians removed per-user Teams local data for both the New Teams package (MSTeams_8wekyb3d8bbwe) and the Classic client; clearing all files from the local Teams cache/data directories and restarting the desktop client restored the Files tab and resolved file open/download errors in the cases observed. Relevant locations included the per-user Microsoft Teams appdata cache (%appdata%\Microsoft\Teams\Cache and sibling folders such as blob_storage, Cache, databases, GPUCache, IndexedDB, Local Storage, tmp) and the New Teams package area under C:\Users\%username%\AppData\Local\Packages. Basic app restarts and local refresh (Ctrl+Alt+F5) had often failed before cache/data removal. Deleting local cache/data did not remove cloud-stored chat or channel messages. Where UI elements remained missing, users accessed files via Teams' Shared view or used 'open in browser' as a practical workaround. Cross-browser checks and review of SSO/SSPR and VPN flows were used to rule out server-side permission or service issues.

Incidents were resolved by a mix of client‑side remediation, application updates, network‑context changes, and occasional spontaneous recovery. Running the IU Self‑Service Tool’s “Repair Teams” operation restored Teams sign‑in and full functionality in multiple cases. Clearing Teams application caches and installing the latest Teams desktop update removed recurring connection‑warning banners and sign‑in loops and restored meetings, messaging, and client search; when cache clearing and updates did not immediately resolve disconnections or meeting drops, reinstalling the latest Teams client (or uninstalling and reinstalling on macOS) was applied. OneDrive sign‑in failures that returned “An unexpected error occurred.” (for example code 2147943811) were resolved after installing and executing the IU Self‑Service Tool and reattempting sign‑in. In at least one report where both Teams and Outlook desktop were nonfunctional, applying OS updates, updating Outlook and Teams, and restarting the PC restored desktop app functionality. Devices on restricted or guest networks (including captive portals) frequently prevented Company Portal or Office app sign‑in; switching network context (for example to a mobile hotspot) restored connectivity and allowed sign‑in in several incidents. A small number of stubborn cases required hard resets or full device reimage after other remediation had no effect. Several users relied on Teams and Outlook via office.com as a temporary workaround while desktop troubleshooting proceeded. Multiple Outlook desktop UI failures (for example the “Action required – Your account needs attention” banner with a nonresponsive “Check account” link, recipient name resolution showing “search...”, or inability to save/send files) followed the same remediation patterns or self‑resolved over days to weeks. Reports also included concurrent OneNote sign‑in failures; in at least one case attempts to repair or uninstall Office produced an error dialog that blocked repair and complicated remediation, prompting escalation to remote support or device reimage.

The incidents were resolved by fully removing all Office application remnants and performing a fresh, support-controlled reinstallation of the Office package via Self Service+. Technicians restarted the device to apply Self Service+ updates, completed a complete uninstall per the Office removal guidance, rebooted, and then performed the reinstall using Self Service+/support-controlled install. Users had previously attempted a Self Service reinstall which did not resolve the issue; after the full uninstall and support-managed reinstall, Excel, Word and Outlook opened and behaved normally.

Issues were resolved by restoring a correct and consistent Microsoft 365 license state and allowing license attributes to propagate. Technicians removed duplicate or conflicting license assignments (including cases where an older SKU persisted alongside a new one and produced Admin Center errors), replaced limited SKUs with licenses that included required capabilities (for example replacing A1/browser-only SKUs when desktop installs were needed or adding A1+AAD when an A1 pool was exhausted), and re-applied licenses manually when automated provisioning failed. After correct assignment and short propagation periods (minutes to days) Outlook, Teams and other apps appeared in users’ Microsoft 365 profiles, office.com and institutional portals, and desktop installers became available. For external users who kept an active account but were not entitled to desktop installs, technicians confirmed the entitlement and advised use of Office Online (office.com). For macOS Company Portal or device-visibility issues technicians confirmed device enrollment/provider alignment or directed users to download licensed apps from office.com when the Company Portal showed 'no apps enabled' or a provider-registration prompt. Microsoft Project desktop versus Project Online behavior was clarified when users encountered PWA permission messages. Transient service-side changes (for example a Copilot license causing temporary Microsoft To Do failures) were observed to self-resolve in some cases. Client-side recurring loading failures were mitigated by clearing local Office caches (for example files under %LOCALAPPDATA%\Microsoft\... such as WeF/HubAppFileCache) and restarting clients. For service accounts not managed by Okta, required SKUs were procured and assigned using licensing paths that did not rely on Okta-group mapping or Entra synchronization.

Cases were resolved either by restoring or delegating missing SharePoint permissions, provisioning required sites or content, or by supplying the correct data sources for page webparts and coordinating with code/site owners. For permission-related incidents administrators assigned appropriate SharePoint site permissions or created the requested sites; after those changes requesters confirmed content returned via Care and Salesforce. Where student tenant-level privileges were absent (for example, Teams assignment file uploads failing because the student account lacked upload/assignment scope), incidents were escalated or referred to Student Support. For webpart and filter failures support created and populated dedicated SharePoint lists or used termstore/termsets as the webpart data source and coordinated with owners of custom code or the site to ensure webparts consumed taxonomy and multi-value fields; some of these items were deprioritized or split into internal follow-ups with owners assigned. Tickets that included broader research-infrastructure requirements were split into internal subtasks and routed to the appropriate teams.

Microsoft Forms was evaluated and found unsuitable for external/anonymous intake scenarios that required file uploads, very long dropdown option lists, and structured, repeatable entries. During triage the team discovered a per-question character limit of about 4000 characters that prevented extremely long dropdowns, and that switching a form to 'Anyone can respond' greys out File upload and removes scheduling, response-limit, and confirmation-email settings. Forms Pro had been migrated to Dynamics 365 Customer Voice and Customer Voice was not in use in the organization, so it was not an immediately available alternative; the requester implemented a temporary workaround for the current year while longer-term options were assessed. Implementations that resolved the requirements included: a Power Apps front end backed by SharePoint document libraries and Power Automate to accept external files, support complex/table-like layouts and repeatable item groups, and persist files and records into SharePoint lists; third-party hosted form providers (for example, JotForm) with automated syncing into SharePoint, Excel, or Google Sheets when a simpler hosted form was acceptable; a Custom Copilot prototype built in Copilot Studio (run from a service/test account) to provide guided, conversational assistance with Copilot output captured as structured JSON/CSV or written into SharePoint/Excel so repeated entries remained mappable; and short-term/ad-hoc file collection via external transfer services (Dropbox, WeTransfer) or a public website form with manual or automated syncing into SharePoint. Chatbot-based collection efforts focused on producing structured exports or direct writes to tabular stores so multiple positions per submission could be uniquely identified and mapped.

IT advised that the organisation's standard was Microsoft Office/Excel and that SVERWEISE/VLOOKUP–style reporting should be implemented in Excel. The candidate's Google Sheets experience was acknowledged as transferable at a conceptual level, but final implementations and integrations were expected to follow the organisation's Excel-based toolset.

Resolutions depended on whether preserving the original form ID and historical responses was required and on which identity the Power Automate connector used. Where preserving the original form was required, tenant administrators moved or rehomed the form into the appropriate Office 365 group so the form retained its original ID, response history, and stored file uploads in the group’s SharePoint document library. Where uploaded files were landing in an individual’s OneDrive, the issue was resolved by moving ownership of the form to a service account or into the Team/group so uploads landed in the service account’s OneDrive Apps/Microsoft Forms/ folder or the group’s SharePoint library. For scenarios where a copy was acceptable, the form was duplicated under the service/team account; the duplicate used a new form ID and had no historical responses, but its upload destination and permissions were linked to the service/account or group.

Flow failures were traced to two common causes and were resolved accordingly: triggers/actions referenced different form IDs (for example a retained trigger pointing at the original form while a “Retrieve response details” action referenced the copied form), and the Power Automate connection identity lacked access to the form. Incidents were resolved by retargeting or reattaching triggers/actions to the preserved form ID, re-authenticating or replacing the Power Automate connector with the account that owned (or had collaborator access to) the form, or adding the service account and required users as owners/collaborators on the form so the connector identity had rights. Where ownership transfer or rehoming was not possible, teams retained the original form to preserve responses, exported response history to Excel for reporting, and recreated the form structure in the destination Team using “Share as template.” SharePoint pages and any stored form URLs/IDs were updated when the final target form ID changed.

Requests to grant users access to the service account’s mailbox or to rename the service account’s email address were handled as separate tenant-directory or Exchange tasks; in practice, access to uploaded files and form management was typically provided by making the users collaborators/owners on the form (or moving the form into the group) rather than sharing mailbox credentials. These actions collectively resolved access, file-storage, and flow-integration failures across the reported incidents.

Access was restored through combined account-, device-, and network-level actions. Support reissued expired or invalid Microsoft 365 activation/invitation links and confirmed that affected accounts were active and had appropriate Microsoft 365 licenses; cases reporting "no license assigned" were resolved after license/portal fixes. Many accounts regained access after password resets—either provider-initiated in Okta for SSO accounts or via reset links sent to users' alternate/private emails—particularly when initial reset messages had been routed to an inaccessible IU mailbox. One Windows Hello PIN creation failure with error 0x801c044f was resolved after an administrator modified specific user account attributes; other PIN failures were recorded where only transient troubleshooting was attempted (retrying the PIN flow, signing out and back in, restarting the device). Where Company Portal/Intune enrollment or app sign‑in still failed after account-side fixes, full workstation reimage restored enrollment and application sign‑in. Several incidents presented as network-related authentication blocks: temporarily connecting via an alternate network (mobile hotspot/different Wi‑Fi) restored access and a subsequent backend network fix resolved the issue permanently. Multiple tickets recorded Outlook clients retaining locally cached mail while send/reply/forward were disabled after failed sign-ins; in those cases password resets sometimes appeared to succeed while access remained blocked and further account- or device-level remediation was required. Separately, a subset of incidents involved external/guest accounts (for example, external lecturers) that were provisioned for web-only access; those users regained access after being informed of the account type and using Okta (okta.iu.org) or office.com in a web browser rather than attempting desktop app sign-in.

IT confirmed Brand‑Space/Frontify was not under the team's management and advised contacting the brand owners. IT then granted the requester access to the IUG‑Marketing‑Templates SharePoint document library (IU_OfficeTemplates - All Documents). The requester uploaded and overwrote the PowerPoint .potx/.potm template files in that repository, and the updated templates replaced the old branding for users referencing that library.

Support verified Microsoft’s public retirement announcement that Viva Goals had been retired and was scheduled for full shutdown on December 31, 2025. Affected users either saw a 'Viva Goals is retired' message or could not complete sign‑in; tenants whose licenses had already expired lost access before the shutdown date. Microsoft confirmed there was no extension or grace period and that access to the platform and its data was no longer available. Because the service was decommissioned, no remediation was possible and the requester was informed before the ticket was closed as resolved.

Two distinct root causes were identified and resolved.

The issue was resolved in two distinct ways depending on the symptom. When the Teams add-in was present but disabled, reactivating the Microsoft Teams Meeting Add-in from Outlook's Disabled Items list restored Teams meeting link functionality in Outlook. When the add-in was missing from Outlook's add-ins list, reinstalling the Microsoft Teams desktop client restored the add-in and rebuilt Outlook–Teams integration so users could schedule Teams meetings again.

When the LMS in-browser viewer/editor failed to open or allow editing of a course document, support obtained the file via the LMS download control and opened the downloaded copy in the native Office application (Excel or Word), which restored access and editing. In one LMS365 incident the browser returned a 'target server refused the connection' error and common client-side remedies (incognito/InPrivate, clearing cache and cookies, signing out and back in, and trying multiple browsers) did not restore in-browser access; that case was escalated for a remote support session (Teams) for further investigation.

The problem was resolved by clearing cached Loop session data and reinitializing the Loop web/desktop app. After browser cache and cookies were cleared and the user rejoined the Loop Web App, the Loop app was (re)installed from the Loop Web App → Settings → Apps entry and opened. Following that refresh, existing components rendered normally in the Loop app and new components could be created in the workspace. Outlook and Teams views remained unaffected throughout.

The export failures were traced to accumulated or phantom animation timing entries on affected slides. Presentations that had repeated recordings and deletions accrued duplicate/extra timing entries which corrupted the export process. Removing the duplicate or extra animation/timing entries from the Animation Pane on the problematic slides and then re-recording the affected timings resolved the corruption and allowed MP4 exports to complete successfully (issues were observed on PowerPoint 16.86 on macOS Sonoma). Some users observed truncated MP4s (~25 seconds) or intermittent behavior; a restart sometimes allowed one successful export but did not address the root cause. A minority of reports documented spontaneous resolution without recorded intervention.

A usable export of a single user chat was produced by selecting the entire conversation in the Teams client, copying it (Ctrl+A, Ctrl+C) and pasting it into a local text file; that manually‑copied transcript was accepted by Copilot. For larger or team‑wide exports there was no single built‑in one‑click export available without Compliance/eDiscovery or elevated admin rights, so teams obtained content by other means: Microsoft Graph API calls to pull channel messages, Teams PowerShell to enumerate/team‑level metadata, and exporting files from the team’s associated SharePoint site (via SharePoint admin/site download or migration tools). Third‑party backup/archive products (for example AvePoint and Veeam Backup for Microsoft 365) were used where a complete, restorable team export or scheduled backups were required. Some approaches required appropriate admin or owner permissions and/or Compliance Center access for full message or eDiscovery exports.

The specialist team increased/adjusted the JungleMail usage limit/quota (work was coordinated with prior related support records). After the quota was raised the newsletter was sent successfully and delivery confirmation was received.

An updated/current co-branding Microsoft Forms link was obtained from the Marketing (jobads) team and the expired link used by Matchmakers was replaced. The new link restored partners' ability to access the form and create public job postings.

Manufacturer-supplied driver and firmware updates applied via vendor tools resolved most incidents where Microsoft 365 desktop apps, browsers, and other applications became slow or unresponsive on Windows laptops under heavy load. Dell systems were scanned with Dell SupportAssist and updated; Dell Command Update found and applied additional vendor driver updates. Lenovo systems were remediated by running Lenovo System Update to install device drivers and BIOS/firmware updates; installing those updates also resolved severe Microsoft Teams meeting connectivity issues on Lenovo hardware. Reducing the number of concurrent heavy applications and open browser tabs consistently improved responsiveness and lowered CPU/fan activity. For one reproducible desktop Excel crash on a Dell Latitude 5450 (Windows 11), the IU Self Service Tool (repair kit) and its Office repair were executed and Windows updates/restarts were attempted but did not stop the freeze/crash; that specific failure required provisioning a replacement machine.

For the on-site German event (~270 attendees) the session was run as a Microsoft Teams meeting/call and Teams' built-in live captions/subtitles (translated captions) were enabled to provide real-time English subtitles beside the stage; this addressed the need for live translated captions rather than a post-event transcript. Zoom had been trialed but produced suboptimal results and appeared to require additional licensing or an add-on, so the Teams approach was accepted and approved. For a separate request to auto-transcribe a meeting into Polish the user was advised to check Microsoft Teams' Live Transcription feature for availability. A suggested alternative, DeepL Voice, required a subscription which the organisation did not hold, so no deployment was performed and the ticket was closed. Tickets noted that personal data (e.g., names and addresses) would be processed.

Duplicate Adaptive Card posts and reply loops were resolved by aligning the Power Automate designer view with documentation (the 'new designer' toggle was turned off where needed) and by narrowing flow conditions so the flow targeted the specific chat (chat URL/ID) and ignored messages created by the flow owner/service account; this eliminated flows reacting to their own messages and stopped repeated posts. Separate duplicate-notification cases in approval flows were resolved by reviewing the approval flow logic, removing redundant notification actions, consolidating notifications to a single channel where appropriate (email OR Teams), and suppressing unnecessary post‑approval confirmation messages when the external billing tool already recorded the approval. As a user-level mitigation, an Outlook rule was suggested to reduce inbox noise while the flow was corrected. After these changes, intermittent errors and repeated notifications ceased.

Incidents were commonly resolved by re-establishing the device’s managed Intune/Company Portal context and restoring desktop OneDrive authentication. Installing or reinstalling the organisation’s Company Portal on affected devices frequently restored OneDrive sync and cleared desktop authentication issues for OneDrive, Outlook and Teams. Starting or signing into the OneDrive desktop app restored access to files and corrected Word-open failures in multiple cases. Other recurring successful remediations included signing out of Teams and OneDrive, restarting the device, and signing back in (sometimes requiring multiple sign-in attempts). A subset of Outlook launch/failure cases was resolved by repairing or resetting the Outlook profile, or by using the browser-based Outlook as a temporary workaround. Desktop-only app instability (for example Word closing when selecting “Enable Content,” Outlook crashing or failing to open, and Teams showing missing groups despite cache clearing) was sometimes resolved by repairing or uninstalling and reinstalling Office; clearing the Teams cache was not a reliable fix. A number of incidents correlated with device compliance or update problems: devices marked “not compliant,” prolonged/failed updates or interrupted installations (including unexpected power-offs) and planned device resets were associated with sign-in failures, and completing a reset or remediation of the device state restored access in several cases. At least one incident noted a previously blocked corporate account in other systems and access was restored later, indicating account-side blocks or compliance status can coincide with client-side failures. A minority of tickets lacked documented closure steps.

Support confirmed that the account license was active in cases where Office applications were not shown. When apps were missing from the portal's default view, the user selected the portal's 'Apps' tab and the Office applications became visible. In separate incidents where the portal returned the error "A service outage has occurred...", the issue was transient and resolved spontaneously; affected apps (Teams, Outlook) were still launchable via the SharePoint App Launcher during the outage. Support did not perform remediation for the service outage events.

In multiple incidents the Office installer initially presented authorization prompts or showed an error/incomplete status but completed automatically after the device remained powered on and connected to the internet. Support observed an extra background installation pass that finished the product even when the setup UI still reported failure; Office installation log files were reviewed and confirmed the product had been installed on the client. On some devices (including recently provisioned laptops) the Office apps were installed but not immediately visible in the Start menu or app list; affected users found the apps by searching the Windows search bar/Start menu for application names (for example, Word or Excel) and then launched them and pinned them to the taskbar to keep them accessible. For users needing immediate PDF viewing while Office apps finished installing, support suggested using an alternate PDF viewer (for example, Adobe Reader).

Support investigated and escalated to a specialist. Per Microsoft documentation, the Excel Online (Business) connector only exposed the manual "For a selected row" trigger; there was no built-in automated "When a row is added to a table" trigger for that connector. As a result, the team documented this connector limitation and recommended using a SharePoint list (or other supported data source) where Power Automate provided native automated triggers.

Support reproduced the browser-specific failure and applied a remediation. After the change the embedded form loaded correctly in Firefox, Chrome and in a private browsing window; testers confirmed the embedded form was accessible. The ticket noted the fix worked across multiple browsers though the root cause detail was not recorded in the ticket.

A consultant scheduled a follow-up demonstration and presented SharePoint and Microsoft 365 built-in tools as potential solutions. The demonstration showcased SharePoint lists and sites, process automation and status-tracking patterns, commenting and collaboration options, and how those components could be combined into a central, cross-departmental feedback/complaint tracking solution as an alternative to Jira/Confluence/Monday.com.

Microsoft Bookings was used as the standard self‑service booking solution where its feature set matched requirements: it supported multi‑staff services (as separate-staff service configurations), location-based services, external-user booking, required contact fields, calendar views and built-in confirmation/reminder messaging, and it was available via customers’ Office 365 subscriptions and Okta SSO. For scenarios that exceeded Bookings’ native capabilities, Power Automate was used to extend functionality — for example attaching iCalendar (.ics) files to messages, implementing advanced reminder or cancellation flows, and integrating bookings with other systems. Research and testing found that Bookings did not permit selecting two specific staff members for a single appointment (a fatal limitation for final‑thesis colloquium workflows requiring both 1st and 2nd examiners); where that requirement existed scheduling remained manual or required evaluation of alternate tooling (for example Calendly or campus-specific systems) or bespoke integrations. It was also determined that Power Automate could not send SMS natively; SMS delivery required integration with a paid third‑party SMS gateway/provider, which required procurement, assignment to the appropriate cost centre and review of legal/data‑protection implications before deployment. For typical recruitment/interview and office‑hours use cases, initial implementations were completed quickly by configuring services, adding staff and availability, and completing content details; ad hoc Teams‑based support was provided to finish setups when requested.

Support compiled and documented the Canadian transcript requirements and identified the gaps in the UFred generation process: inclusion of course start/end dates, course codes/names, credits for degree programs and hours for certificates, program-appropriate grade formats, a transcript legend on the reverse, and signed/sealed output for validity in Canada. The documentation clarified that the document-generation/template team (within the M365/UFred tenant context) was the responsible owner to implement these template and process changes.

Investigations identified two primary causes for missing in‑app UI while backend triggers or alternate interfaces referenced the same capability. First, the in‑app editor or view had been removed, restricted, or not yet propagated to some tenants during staged rollouts; affected customers were informed the UI was unavailable in that app build while automation or API paths could still be used. Second, availability was controlled by tenant preview gating, tenant policies, or tenant configuration flags rather than licensing; examples included Loop preview groups and Microsoft 365 tenant config flags (for example TenantConfig.IsGroupFoldersAndRulesEnabled). Support confirmed required licenses (for example Copilot for Planner Project Manager) did not guarantee UI visibility. Resolutions included adding users to the tenant's preview group or applying the tenant preview policy, having a tenant administrator enable the relevant TenantConfig feature flag, awaiting product rollout propagation (often several hours and sometimes up to ~24 hours), or escalating to the product team when the behavior resulted from a broader rollout issue or intentional product change; those escalations were resolved by product fixes or clarified rollout timelines. The discrepancy between backend triggers and in‑app visibility was attributed to separate deployment and availability paths for backend automation endpoints (Power Automate / Microsoft Graph) versus in‑app preview features. When requesters lacked admin rights, resolution depended on tenant administrators applying preview policies or flags and on propagation delays. For a Word-specific occurrence where the 'Export to PowerPoint' option was absent and Word only showed 'Web page' or 'Kindle', support proposed a pragmatic workaround of exporting the document as a PDF and inserting that PDF into PowerPoint; that ticket was closed without confirmation the workaround had been applied.

Access was restored by opening the Entra (Azure AD) admin portal directly using the new Entra URL (https://entra.microsoft.com/#view/Microsoft_AAD_IAM/EntraLanding.ReactView) and performing the required admin actions there. The root cause was a propagation/redirect change for the new Entra link that had not reached the Microsoft 365 admin center entry points, so using the direct Entra URL bypassed the broken/propagating route and recovered administrative access.

Support determined that licensing and Okta/DOI sign-in were not the root cause; affected users retained assigned Office A1 licenses and SSO completed. Primary causes were conflicting Microsoft accounts (including guest/duplicate identities), stale browser/session cookie state, and in some cases recent account-identifier (email or display-name) changes that had not fully propagated. Access was restored in most incidents by creating an isolated auth context — opening a private/incognito window, using a different browser or profile, or signing out of all Microsoft web sessions and explicitly signing back in with the institution account. Clearing or deleting Teams-related cookies removed stale auth state in at least one case; switching browsers resolved partial UI rendering in others. In incidents where duplicate/guest accounts produced persistent sign-in loops, high CPU usage or unresponsive clients, symptoms subsided after the guest/secondary account was removed or after a full sign-out and reauthentication into the institution account. Identity/permission propagation delays explained cases where recordings/transcripts or resources did not map to the user’s current account until propagation completed. Temporary workarounds observed included creating a new Loop board when shared boards would not open. On private/personal devices where the Teams web tile failed to open, advising use of the Teams desktop client or reinstalling the Teams mobile app closed related tickets when web-session fixes were not possible. One support case noted missing OEM utilities (Dell SupportAssist) preventing firmware updates; that was tracked separately from the account/cookie root cause.

The issue was resolved by editing the specific Bookings service and updating its service configuration: adding and marking the required custom field(s) in the service's Custom fields section and saving the changes restored Teams meeting links in subsequent appointment confirmations.

Transient desktop Excel failures were resolved in multiple incidents by opening the same workbook or Dataverse dataset in Excel Online (browser) and then reopening the desktop Excel app; after that the desktop client opened files normally. In a Dataverse-specific incident the Excel client could not load a dataset while browser editing worked; Excel had begun hanging and crashing after a recent Office update and the issue ultimately cleared without a confirmed corrective action. Support had noted an uninitialized or blocked Dataverse Excel add-in (including a possible rejected add-in prompt) as a likely client-side cause and documented add-in troubleshooting, but no specific remediation was confirmed for that case. Separately, some user-facing Office warning popups were traced to a Microsoft service incident (Incident ID OD843843 reported 2024-07-31); those occurrences matched a known Microsoft outage and no local remediation was available while Microsoft investigated.

IT confirmed that the environment's Word did not include a built-in APA 7 style/template. Support recommended using a reference-management tool that supports APA 7 (example: Zotero) or obtaining an APA 7 Word template/style from the APA Style resources, since no IT-managed APA 7 template was deployed.

Support confirmed they did not have access to the form. The issue was resolved when the form owner/creator re-enabled the form to accept responses; after the owner changed the acceptance setting the form began accepting submissions again. (Ticket included diagnostic IDs: Session ID 5f552e2f-a3d4-4eba-a44e-ac390b476aeb, Correlation ID 2d317ec8-6284-465d-95f9-efaadfb0a047.)

Incidents were attributed to several distinct root causes and were resolved by targeted actions matching each cause.

Where a browser or mobile client worked but the desktop app did not, investigations consistently pointed to either a desktop client bug, file‑level corruption, or device‑specific add‑ins/policy. Resolutions therefore ranged from repairing/updating the Office client and disabling problematic add‑ins to recreating or re‑saving the workbook; several tickets had no confirmed remedial action recorded.

The behaviour was a limitation of the Teams Add members UI: it did not accept bulk‑pasted lists of email addresses. The situation was resolved by importing the addresses outside the Teams add dialog (for example by creating a distribution list / Microsoft 365 group or adding users in bulk via Exchange/Outlook or a PowerShell/Graph bulk add) and then adding that group or the imported members into the Team. This avoided pasting multiple addresses into the Teams membership dialog.

Provisioning on the syntea.com domain was blocked because the domain was not supported/approved for mailboxes in the tenant. The request was fulfilled by creating the requested mailboxes/service accounts and a Teams workspace under the organisation's verified domain instead, and by using shared/mailbox or service‑account patterns for multi‑user access. Phone/WhatsApp contact options were treated as separate vendor/telecom arrangements outside the tenant and were not provisioned on the external domain.

The issue was resolved by recreating the questionnaire in the modern Microsoft Forms experience (a new form created under current Forms) and restoring management access by transferring ownership/sharing with the admin. Existing Power Automate flows and SharePoint connections were re-pointed or recreated to reference the new form. After the form was re-created under the current Forms type and ownership/permissions were corrected, the Multilingual setting became available and an English version was added.

Support clarified that the user who creates a Teams group is automatically assigned as a member and does not need to add themselves via the member search. After this clarification the user confirmed they no longer needed to search for their own name and considered the issue resolved.

The partially visible content was salvaged from the file preview, a new PPTX was created, and the presentation was manually rebuilt by copying or recreating the visible slides/content into the new file. Saving the rebuilt presentation restored a working copy of the deck.

Support verified that clicking 'Synchronize' only created a locally mounted/synced view of the SharePoint document library in the user's OS file manager and did not move, copy, or delete any files. Permissions were unchanged, files remained intact and accessible through SharePoint and the Teams channel, and the user's concern was resolved after confirmation of file integrity. The ticket was closed once the user acknowledged no data loss.

Support manually sent the user the invitation/confirmation email and confirmed delivery; the manual resend occurred on 2024-10-16 at 15:46 and the issue was marked Done after the user received the message.

Support identified the persistent pop-up as a third-party AI companion (likely otter.ai) integrated with the user's Teams account. The issue was resolved by addressing the companion app: the auto-join behaviour was disabled in the third‑party app settings or the app/integration was removed/uninstalled from the user's Teams account, after which the pop-up no longer appeared during meetings.

Investigators confirmed the service account UPN had been changed to fs-lernapp-keycloak@svc.iu-it.org while smtp.office365.com remained the SMTP host. The Keycloak/Docker service environment was updated to use the new service account credentials (replaced the .env/credential values for the mail sender). After the credential change the Docker tests no longer returned ECONNREFUSED and the monthly emails resumed sending from the service account.

IT staff created the requested Team and channel structure during a joint call and applied channel moderation and membership controls to match the unit's specifications. Channels were created per study cluster (e.g., Marketing), channel moderation was enabled so staff acted as posters/moderators while students could comment, and a single FAQ channel was left writable by students. Membership was managed by staff additions tied to the subset of students active on JobTeaser. The delivered configuration satisfied the posting, moderation, and membership requirements.

The issue was intermittent and cleared without a technical intervention; the reporter later confirmed the Print Notes Pages function produced notes as expected. Support could not reproduce the problem across different operating systems and browsers, and no configuration change or fix was applied during the incident. The case was documented for escalation if the symptom recurred.

The root cause was the extremely large count of embedded images in the workbook. The fix removed the embedded images (approximately 96,800, many appearing as 1×1 pixel images from cell formatting), after which Excel and LibreOffice opened the file normally and CPU usage returned to expected levels. Identifying and eliminating the bulk embedded objects resolved the freezing and performance issues.

The behaviour was traced to a Microsoft-side service bug (incident OD843843). No client-side or local remediation was applied; users continued to bypass the prompt with the "Ignore" → "Yes" sequence until Microsoft remediated the incident. Once Microsoft addressed the service issue, the persistent warning dialogs ceased and normal document opening resumed.

Support implemented a change on the LMS365 service (server-side fix) which removed the runtime TypeError. After the service-side fix was applied, the user retried and confirmed successful login; no client/browser configuration changes were required and no further errors were reported.

Clearing the Teams client cache resolved multiple client-side symptoms. After both the new Teams and classic Teams caches were cleared and the client restarted, missing in‑client apps (including Shifts and Workday) reappeared and camera visibility returned to normal. The same cache clearance behavior was recorded for authentication failures that produced sign‑in loops and contacts shown as offline; tickets traced these failures to recent client or Windows/driver updates. A related calendar display gap affecting a specific multi‑week date range was consistent with either client cache corruption or service/calendar data issues; commonplace remediation attempts such as password reset, sign‑out/sign‑in, and restarts did not fix the calendar gap in affected cases. Support notes included that cache‑clear instructions must target the correct filesystem locations for the deployed client: both the MS Store package instance (identified by MSTeams_8wekyb3d8bbwe or similar package folders) and the classic Teams profile cache under %appdata%\Microsoft\Teams were referenced, and some cache‑clear attempts failed when the expected AppData/filesystem path was not present in the user profile.

Multiple incidents of repeated Teams desktop crashes were resolved by reinstalling the Teams desktop client; a clean removal and fresh install of the current Teams build stopped the frequent unexpected closures in several cases. In one case the user-reported cause was addressed after applying system/Teams/driver updates, after which call crashes with a black screen and audio loss ceased. Support also documented alternative mitigations used or recommended during triage: clearing the Teams local cache and using the Teams web client were recorded as temporary workarounds, and investigations included updating or reviewing graphics drivers, BIOS, and other device drivers where hardware/driver interaction was suspected (some instances persisted after a GPU driver update).

The Adobe Cloud AddIn was reactivated through Outlook's COM Add-Ins management and Outlook was restarted. After re-enabling the add-in and restarting the client, the add-in loaded and its features returned.

It was confirmed that Microsoft Forms did not support embedding an Excel workbook or table directly inside a form, and did not provide repeating sections or integrated table-like logic for collecting multiple rows per entity. The requested table-style layout and multi-row/grouped-entry functionality could not be implemented within Forms. The practical workaround used was to host the table or spreadsheet in OneDrive or SharePoint and insert a link to that file within the form so respondents could open and complete it separately.

Access was restored after the user followed an emailed expiry/extension prompt to extend the Planner's expiration. Once the expiration was extended via the email workflow, the user's Planner and tasks became accessible again.

Microsoft support confirmed that the 'include chat history' prompt appears only the first time a member is added and that there was no way to retroactively attach full history after the option was absent. Users worked around the limitation by manually copying or resending prior messages or screenshots to the new participant.

Support reviewed the user's workflow and concluded that Jira did not meet the requirement. The issue was addressed by recommending synchronization of the relevant Planner plan with the user's Outlook calendar so that plan tasks were surfaced in the calendar (with the possibility of being marked complete from the calendar view). The ticket was closed after the consultation and recommendation.

The ticket recorded that the per-board bucket limit (200 buckets) had been reached and no specific technical remediation steps were logged. The service returned to normal at a later time and users were again able to create new buckets. The observable resolution was restoration of bucket capacity and resumed ability for students to add cards; no tenant-side changes were documented in the ticket.

The customer engaged an internal IT engineer and opened a Microsoft Support service request to investigate Bookings' availability checks. Support found conflicts between Bookings' availability queries and the affected staff Outlook calendars (compounded by merged service/locale mappings and existing absence‑block calendar entries). After correcting calendar mappings/permissions and aligning how Bookings read staff free/busy information, Bookings' availability matched users' Outlook calendars and the double‑booking incidents ceased.

The request was closed after the parent deployment work was completed. The rollout had been implemented by obtaining formal approval from the branding owners, collecting the approved background image files from the Brand Hub, and deploying them centrally via Teams admin customization (client customization policies / meeting background distribution). The deployed backgrounds became available to clients through the Teams customization policy rather than relying on ad‑hoc user uploads.

The failures were traced to sharing scope and where Teams surfaces meeting files (OneDrive for private meeting chats, the team/channel SharePoint site for channel meetings). Channel meetings additionally enforced a team-members-only chat access policy, causing the explicit error 'Chat is not available. In channel meetings only members of the team have access to the chat.' Incidents were resolved by locating the recording/file in the meeting or channel Files location (SharePoint/OneDrive) and correcting its access so it matched the attendee set: files were re-shared from the appropriate SharePoint/OneDrive location with a broader sharing scope (organization-visible link) or with explicit guest access, or affected users were given membership/explicit permission on the team/site. After the file-links and permissions were adjusted and recipients were signed in or granted access, users were able to download the PDFs/recordings normally.

Investigations reproduced a media-stack conflict: when the same machine attempted to host both an active Teams presentation (screen share with system audio) and a browser-based Vonage call, the VoIP client and Teams competed for audio/control and Teams ejected the presenter while the external call dropped (Vonage UI sometimes showed 'logging the call'). The behavior occurred for both outgoing and incoming/accepted Vonage calls during an active share and reproduced on Windows with Chrome, with a wired headset detected and with the Teams desktop client in use. Troubleshooting such as clearing Chrome and Teams caches and restarting sessions was attempted in at least one case but did not produce a confirmed fix. The issue was stopped by separating the Vonage call from the presenting session: presenters placed or accepted Vonage calls from a second device, or paused/ended screen‑share before initiating/accepting the call, or used the Teams desktop client with system‑audio sharing configured so the Vonage client did not claim exclusive audio/control. After the presentation/call setup was changed so the Vonage call did not run concurrently on the presenting machine, the unexpected ejections and call dropouts ceased.

The issue was resolved by installing/adding Microsoft Planner from the Teams Apps catalogue first, then adding the Planner board as a tab in the chat. In this environment Planner was not exposed directly via the chat add-tab flow and required selecting the Planner app from the Teams app selection before a board could be attached to the chat.

Support investigated and confirmed affected users were running Office for Mac, where a subset of advanced and customization features is not implemented compared with the Windows desktop client. Specific observations included Excel for Mac lacking advanced tools such as Filters and Data Validation, and Word for Mac lacking the Design→Colors 'Customize Colors' option and the Draw→Colours customization dialog; Word Online offered only theme/design suggestions and did not present a color-customization dialog. Colleagues and platform documentation corroborated these were platform limitations; no configuration change or local workaround enabled the missing options and no changes were applied to the users' clients. Support noted the Windows desktop Office client provided the fuller feature set for these scenarios and informed users accordingly when feature parity was required.

Investigation showed that modifying attendee lists on a recurring Teams/Outlook meeting caused the platform to send an update to all existing attendees; no tenant setting or Teams feature was found to suppress update notifications for added participants. The support team documented and communicated alternative options to the requester (for example: hosting a separate meeting series for the new participants or using announcement methods outside the meeting invite). No technical change was implemented because the behavior was a product limitation.

Support verified affected accounts were not locked and determined the desktop sign‑in failures were caused by license changes or account types that removed desktop Office and OneDrive entitlements, leaving only web access. Incidents were resolved by restoring or assigning a Microsoft 365/edu license that included the desktop Office apps and OneDrive access. In cases where SSO (Okta) sign‑in still failed after license restoration, a password reset was performed and resolved the remaining sign‑in issue. Several incidents involved external/guest users who were unlicensed for desktop apps and therefore experienced persistent local UI sign‑in errors despite web access.

Support identified that the visible items were personal booking pages rather than a team booking page. The situation was resolved by creating/using a team (shared) booking page in Microsoft Bookings so the booking calendar was owned and visible at the team level rather than under the individual's personal Booking pages.

Internal support was unable to identify a root cause and documented troubleshooting attempts. The issue was escalated to Microsoft Support for investigaton (support case opened) because Bookings appointments were present in Exchange/Outlook but missing from the Bookings portal; no tenant-level fix was recorded by internal support at ticket closure.

Support explained that group renewal notifications are generated when groups meet the tenant's inactivity/expiration criteria and that the in‑email 'renew' action restored the group. Support also advised that if a group was deactivated due to non‑renewal, a support request would be required to restore it; no tenant policy changes were performed by support during the ticket.

Support followed the published transfer procedure and successfully moved ownership of the form from the user's personal account to the team account. The form remained accessible under the same link and was usable by colleagues after the ownership transfer.

Support confirmed that the Normal.dotm template path was not accessible in the user's profile and that copying a colleague's Normal.dotm required administrative privileges. Replacing Normal.dotm did not resolve the persistent macro warning and no Trust Center changes were recorded (administrative access was a blocker). The ticket recorded that the issue persisted and that elevated permissions would be needed to modify the profile template or Trust Center settings.

Support located affected recording files in the Teams channel/SharePoint library and observed multiple symptoms: several recordings were stuck in a 'Saving' state, Stream download links opened blank browser tabs for affected transcript/recording items, and some meetings had duplicate or short unintended recordings alongside the intended long capture. Troubleshooting steps and observations were documented and an engineering investigation item was opened; no tenant‑level configuration change or definitive fix was recorded in the tickets. In at least one reported instance, missing recordings were not actively remediated by support but later appeared in the channel/CF automatically (some files uploaded much later), after which the reporter confirmed the issue resolved.

The ticket recorded that no technical fix was implemented by support before ticket closure. The event was documented as channel‑level muting affecting only certain course groups; no resolution steps were recorded in the ticket.

Support engaged with the user to observe the symptom via Teams screen-share and applied several background updates to the client and system while monitoring. No specific error messages, logs, or a definitive root cause were documented, and the ticket was closed without a confirmed, reproducible fix recorded.

Support advised using Bookings' Shared Booking Page capability and provided the official Microsoft Learn article 'Set up your shared booking page' as the reference. The user was recommended to create a test Shared Booking Page to evaluate available group-appointment options, recurrence behavior, and per-staff configuration; no additional custom configuration or confirmed final setup was documented in the ticket.

Support personnel identified the issue as a client-side font/character-rendering problem rather than a server-side document corruption. A technician diagnosed the symptom as likely caused by a missing or substituted font or encoding mismatch on the affected laptops and scheduled direct inspection/remote troubleshooting of those machines. The ticket recorded the diagnosis and follow-up arrangement but did not document a specific remediation (no font installation or final configuration change was logged).

Support investigation did not implement a final fix before the ticket was closed for inactivity. Troubleshooting notes recorded by support pointed to potential background processes or automation (for example Power Automate/flows, retention/record rules, or other sync/automation) and metadata inconsistencies as likely causes of the folder re‑creation. No remediation or configuration change was applied and the issue remained unresolved in the ticket record.

Support investigated the discrepancy and escalated/monitored the Planner board; the issue was not reproducible on demand and support notes indicated intermittent/opaque service behaviour (including maintenance notices) as the probable contributor. No configuration change or definitive bug-fix was recorded and the ticket was closed without a documented remediation.

No in‑depth remediation was completed because support declined to provide extended help for a private device. Support recorded that the Clear cache action in Android Settings for Teams was unresponsive (cache shown as ~430 KB) and that the app worked on the corporate device but not the private handset. Suggested troubleshooting steps (force‑stop, clear cache via Settings, reinstall) were recommended to the user but no successful sign‑in or reinstall was achieved and no further escalation was performed.

Support confirmed the error message and attempted common local fixes (sign out/sign in and notebook restart) which did not restore camera functionality. The issue was treated as a broader Teams/tenant incident and support advised waiting for a Microsoft-side fix. No on-premises or user‑level remediation succeeded before the ticket was auto‑closed after 14 days with no further updates.

Support showed that Outlook and Teams were available from the Microsoft 365 app launcher after signing in and that access used the same institutional M365 credentials. The user was reminded to use any direct My Campus links provided by instructors, and when those links or credentials had not been received support advised contacting the course instructors' (Dozierenden) guides for the specific login information. Support followed up and assumed the user was able to proceed.

Support documented that the workbook appeared to reference an external Windows‑only file path (example: a mapped N:\ network drive such as N:\Directory\database.db) which macOS and Excel Online could not access; Windows users did not see the problem. The ticket did not record a final remediation or resolution.

No confirmed remediation was recorded in the ticket. Support recommended reinstalling the Teams desktop client and offered the Teams web app (https://teams.cloud.microsoft) as a working workaround. Support attempted phone contact and assigned a colleague to follow up, but the ticket was closed due to no response before a definitive fix was applied.

No final fix was recorded. Support determined the UI message indicated the tenant or team configuration had channel scheduling disabled and noted that Course Feed / learning-category teams can restrict some channel features. Support advised that tenant or Teams admin settings controlling channel meeting scheduling needed to be changed (or the team classification adjusted) so the channel appeared as a scheduling target, but there was no confirmation in the ticket that those changes were applied.